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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 
transporting multi-protocol datagrams over point-to-point links. 


This document describes the use of HDLC-like framing for PPP 
encapsulated packets. 
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1. Introduction 


This specification provides for framing over both bit-oriented and 
octet-oriented synchronous links, and asynchronous links with 8 bits 
of data and no parity. These links MUST be full-duplex, but MAY be 
either dedicated or circuit-switched. 


An escape mechanism is specified to allow control data such as 
XON/XOFF to be transmitted transparently over the link, and to remove 
Spurious control data which may be injected into the link by 
intervening hardware and software. 


Some protocols expect error free transmission, and either provide 
error detection only on a conditional basis, or do not provide it at 
all. PPP uses the HDLC Frame Check Sequence for error detection. 
This is commonly available in hardware implementations, and a 
software implementation is provided. 
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1.1. Specification of Requirements 


In this document, several words are used to signify the requirements 
of the specification. These words are often capitalized. 


MUST 


MUST NOT 


SHOULD 


MAY 


This word, or the adjective "required", means that the 
definition is an absolute requirement of the specification. 


This phrase means that the definition is an absolute 
prohibition of the specification. 


This word, or the adjective "recommended", means that there 
may exist valid reasons in particular circumstances to 
ignore this item, but the full implications must be 
understood and carefully weighed before choosing a 
different course. 


This word, or the adjective "optional", means that this 
item is one of an allowed set of alternatives. An 
implementation which does not include this option MUST be 
prepared to interoperate with another implementation which 
does include the option. 


1.2. Terminology 


This document frequently uses the following terms: 


datagram 


frame 


packet 


peer 


The unit of transmission in the network layer (such as IP). 
A datagram may be encapsulated in one or more packets 
passed to the data link layer. 


The unit of transmission at the data link layer. A frame 
may include a header and/or a trailer, along with some 
number of units of data. 


The basic unit of encapsulation, which is passed across the 
interface between the network layer and the data link 
layer. A packet is usually mapped to a frame; the 
exceptions are when data link layer fragmentation is being 
performed, or when multiple packets are incorporated into a 
single frame. 


The other end of the point-to-point link. 


Silently discard 


Simpson 


The implementation discards the packet without further 
processing. The implementation SHOULD provide the 
capability of logging the error, including the contents of 
the silently discarded packet, and SHOULD record the event 
in a statistics counter. 
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2. Physical Layer Requirements 


PPP is capable of operating across most DTE/DCE interfaces (such as, 
EIA RS-232-E, EIA RS-422, and CCITT V.35). The only absolute 
requirement imposed by PPP is the provision of a full-duplex circuit, 
either dedicated or circuit-switched, which can operate in either an 
asynchronous (start/stop), bit-synchronous, or octet-synchronous 
mode, transparent to PPP Data Link Layer frames. 


Interface Format 


PPP presents an octet interface to the physical layer. There is 
no provision for sub-octets to be supplied or accepted. 


Transmission Rate 


PPP does not impose any restrictions regarding transmission rate, 
other than that of the particular DTE/DCE interface. 


Control Signals 


PPP does not require the use of control signals, such as Request 
To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and 
Data Terminal Ready (DTR). 


When available, using such signals can allow greater functionality 
and performance. In particular, such signals SHOULD be used to 
signal the Up and Down events in the LCP Option Negotiation 
Automaton [1]. When such signals are not available, the 
implementation MUST signal the Up event to LCP upon 
initialization, and SHOULD NOT signal the Down event. 


Because signalling is not required, the physical layer MAY be 
decoupled from the data link layer, hiding the transient details 
of the physical transport. This has implications for mobility in 
cellular radio networks, and other rapidly switching links. 


When moving from cell to cell within the same zone, an 
implementation MAY choose to treat the entire zone as a single 
link, even though transmission is switched among several 
frequencies. The link is considered to be with the central 
control unit for the zone, rather than the individual cell 
transceivers. However, the link SHOULD re-establish its 
configuration whenever the link is switched to a different 
administration. 


Due to the bursty nature of data traffic, some implementations 
have choosen to disconnect the physical layer during periods of 
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inactivity, and reconnect when traffic resumes, without informing 
the data link layer. Robust implementations should avoid using 
this trick over-zealously, since the price for decreased setup 
latency is decreased security.  Implementations SHOULD signal the 
Down event whenever "significant time" has elapsed since the link 
was disconnected. The value for "significant time" is a matter of 
considerable debate, and is based on the tariffs, call setup 
times, and security concerns of the installation. 


3. The Data Link Layer 


PPP uses the principles described in ISO 3309-1979 HDLC frame 
Structure, most recently the fourth edition 3309:1991 [2], which 
Specifies modifications to allow HDLC use in asynchronous 
environments. 


The PPP control procedures use the Control field encodings described 
in ISO 4335-1979 HDLC elements of procedures, most recently the 
fourth edition 4335:1991 [4]. 


This should not be construed to indicate that every feature of the 
above recommendations are included in PPP. Each feature included 
is explicitly described in the following sections. 


To remain consistent with standard Internet practice, and avoid 
confusion for people used to reading RFCs, all binary numbers in the 
following descriptions are in Most Significant Bit to Least 
Significant Bit order, reading from left to right, unless otherwise 
indicated. Note that this is contrary to standard ISO and CCITT 
practice which orders bits as transmitted (network bit order). Keep 
this in mind when comparing this document with the international 
standards documents. 
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3.1. Frame Format 


A summary of the PPP HDLC-like frame structure is shown below. This 
figure does not include bits inserted for synchronization (such as 
start and stop bits for asynchronous links), nor any bits or octets 
inserted for transparency. The fields are transmitted from left to 
right. 
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The Protocol, Information and Padding fields are described in the 
Point-to-Point Protocol Encapsulation [1]. 


Flag Sequence 


Each frame begins and ends with a Flag Sequence, which is the 
binary sequence 01111110 (hexadecimal 0x7e). All implementations 
continuously check for this flag, which is used for frame 
synchronization. 


Only one Flag Sequence is required between two frames. Two 
consecutive Flag Sequences constitute an empty frame, which is 
silently discarded, and not counted as a FCS error. 


Address Field 


The Address field is a single octet, which contains the binary 
sequence 11111111 (hexadecimal Oxff), the All-Stations address. 
Individual station addresses are not assigned. The All-Stations 
address MUST always be recognized and received. 


The use of other address lengths and values may be defined at a 


later time, or by prior agreement. Frames with unrecognized 
Addresses SHOULD be silently discarded. 
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Control Field 


The Control field is a single octet, which contains the binary 
sequence 00000011 (hexadecimal 0x03), the Unnumbered Information 
(UI) command with the Poll/Final (P/F) bit set to zero. 


The use of other Control field values may be defined at a later 
time, or by prior agreement. Frames with unrecognized Control 
field values SHOULD be silently discarded. 


Frame Check Sequence (FCS) Field 


The Frame Check Sequence field defaults to 16 bits (two octets). 
The FCS is transmitted least significant octet first, which 
contains the coefficient of the highest term. 


A 32-bit (four octet) FCS is also defined. Its use may be 
negotiated as described in "PPP LCP Extensions" [5]. 


The use of other FCS lengths may be defined at a later time, or by 
prior agreement. 


The FCS field is calculated over all bits of the Address, Control, 
Protocol, Information and Padding fields, not including any start 
and stop bits (asynchronous) nor any bits (synchronous) or octets 
(asynchronous or synchronous) inserted for transparency. This 

also does not include the Flag Sequences nor the FCS field itself. 


When octets are received which are flagged in the Async- 
Control-Character-Map, they are discarded before calculating 
the FCS. 


For more information on the specification of the FCS, see the 
Appendices. 


The end of the Information and Padding fields is found by locating 


the closing Flag Sequence and removing the Frame Check Sequence 
field. 
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3.2. Modification of the Basic Frame 


The Link Control Protocol can negotiate modifications to the standard 
HDLC-like frame structure. However, modified frames will always be 
clearly distinguishable from standard frames. 


Address-and-Control-Field-Compression 


When using the standard HDLC-like framing, the Address and Control 
fields contain the hexadecimal values Oxff and 0x03 respectively. 
When other Address or Control field values are in use, Address- 
and-Control-Field-Compression MUST NOT be negotiated. 


On transmission, compressed Address and Control fields are simply 
omitted. 


On reception, the Address and Control fields are decompressed by 
examining the first two octets. If they contain the values Oxff 
and 0x03, they are assumed to be the Address and Control fields. 
If not, it is assumed that the fields were compressed and were not 
transmitted. 


By definition, the first octet of a two octet Protocol field 
will never be Oxff (since it is not even). The Protocol field 
value 0x00ff is not allowed (reserved) to avoid ambiguity when 
Protocol-Field-Compression is enabled and the first Information 
field octet is 0x03. 
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4. Octet-stuffed framing 


This chapter summarizes the use of HDLC-like framing with 8-bit 
asynchronous and octet-synchronous links. 


4.1. Flag Sequence 


The Flag Sequence indicates the beginning or end of a frame. The 
octet stream is examined on an octet-by-octet basis for the value 
01111110 (hexadecimal Ox7e). 


4.2. Transparency 


An octet stuffing procedure is used. The Control Escape octet is 
defined as binary 01111101 (hexadecimal 0x7d), most significant bit 
EqJrSt. 


As a minimum, sending implementations MUST escape the Flag Sequence 
and Control Escape octets. 


After FCS computation, the transmitter examines the entire frame 
between the two Flag Sequences. Each Flag Sequence, Control Escape 
octet, and any octet which is flagged in the sending Async-Control- 
Character-Map (ACCM), is replaced by a two octet sequence consisting 
of the Control Escape octet followed by the original octet 
exclusive-or'd with hexadecimal 0x20. 


This is bit 5 complemented, where the bit positions are numbered 
76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE 
when comparing documents). 


Receiving implementations MUST correctly process all Control Escape 
sequences. 


On reception, prior to FCS computation, each octet with value less 
than hexadecimal 0x20 is checked. If it is flagged in the receiving 
ACCM, it is simply removed (it may have been inserted by intervening 
data communications equipment). Each Control Escape octet is also 
removed, and the following octet is exclusive-or'd with hexadecimal 
0x20, unless it is the Flag Sequence (which aborts a frame). 


A few examples may make this more clear.  Escaped data is transmitted 
on the link as follows: 
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Ox7e is encoded as Ox7d, Ox5e. (Flag Sequence) 
Ox7d is encoded as Ox7d, O0x5d. (Control Escape) 
0x03 is encoded as Ox7d, 0x23. (ETX) 


Some modems with software flow control may intercept outgoing DC1 and 
DC3 ignoring the 8th (parity) bit. This data would be transmitted on 
the link as follows: 


0x11 is encoded as Ox7d, 0x31. 
0x13 is encoded as Ox7d, 0x33. 
0x91 is encoded as Ox7d, Oxbl. 
0x93 is encoded as Ox7d, 0xb3. 


XON) 
XOFF) 
XON with parity set) 
XOFF with parity set) 


( 
( 
( 
( 
4.3. Invalid Frames 
Frames which are too short (less than 4 octets when using the 16-bit 
FCS), or which end with a Control Escape octet followed immediately 
by a closing Flag Sequence, or in which octet-framing is violated (by 


transmitting a "0" stop bit where a "1" bit is expected), are 
Silently discarded, and not counted as a FCS error. 


4.4. Time Fill 
4.4.1. Octet-synchronous 
There is no provision for inter-octet time fill. 


The Flag Sequence MUST be transmitted during inter-frame time fill. 


4.4.2. Asynchronous 


Inter-octet time fill MUST be accomplished by transmitting continuous 
"1" bits (mark-hold state). 


Inter-frame time fill can be viewed as extended inter-octet time 
fill. Doing so can save one octet for every frame, decreasing delay 
and increasing bandwidth. This is possible since a Flag Sequence may 
serve as both a frame end and a frame begin. After having received 
any frame, an idle receiver will always be in a frame begin state. 
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Robust transmitters should avoid using this trick over-zealously, 
Since the price for decreased delay is decreased reliability. Noisy 
links may cause the receiver to receive garbage characters and 
interpret them as part of an incoming frame. If the transmitter does 
not send a new opening Flag Sequence before sending the next frame, 
then that frame will be appended to the noise characters causing an 
invalid frame (with high reliability). 


It is suggested that implementations will achieve the best results by 
always sending an opening Flag Sequence if the new frame is not 
back-to-back with the last.  Transmitters SHOULD send an open Flag 
Sequence whenever "appreciable time" has elapsed after the prior 


closing Flag Sequence. The maximum value for "appreciable time" is 
likely to be no greater than the typing rate of a slow typist, about 
1 second. 

4.5. Transmission Considerations 

4.5.1. Octet-synchronous 


The definition of various encodings and scrambling is the 
responsibility of the DTE/DCE equipment in use, and is outside the 
Scope of this specification. 


4.5.2. Asynchronous 
All octets are transmitted least significant bit first, with one 


start bit, eight bits of data, and one stop bit. There is no 
provision for seven bit asynchronous links. 
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5. Bit-stuffed framing 


This chapter summarizes the use of HDLC-like framing with bit- 
synchronous links. 


5.1. Flag Sequence 


The Flag Sequence indicates the beginning or end of a frame, and is 
used for frame synchronization. The bit stream is examined on a 
bit-by-bit basis for the binary sequence 01111110 (hexadecimal 0x7e). 


The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT be 
used. When not avoidable, such an implementation MUST ensure that 
the first Flag Sequence detected (the end of the frame) is promptly 
communicated to the link layer. Use of the shared zero mode hinders 
interoperability with bit-synchronous to asynchronous and bit- 
synchronous to octet-synchronous converters. 


5.2. Transparency 
After FCS computation, the transmitter examines the entire frame 
between the two Flag Sequences. A "0" bit is inserted after all 
sequences of five contiguous "1" bits (including the last 5 bits of 
the FCS) to ensure that a Flag Sequence is not simulated. 


On reception, prior to FCS computation, any "0" bit that directly 
follows five contiguous "1" bits is discarded. 


5.3. Invalid Frames 
Frames which are too short (less than 4 octets when using the 16-bit 


FCS), or which end with a sequence of more than six "1" bits, are 
Silently discarded, and not counted as a FCS error. 


5.4. Time Fill 
There is no provision for inter-octet time fill. 


The Flag Sequence SHOULD be transmitted during inter-frame time fill. 
However, certain types of circuit-switched links require the use of 
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mark idle (continuous ones), particularly those that calculate 
accounting based on periods of bit activity. When mark idle is used 
on a bit-synchronous link, the implementation MUST ensure at least 15 
consecutive "1" bits between Flags during the idle period, and that 
the Flag Sequence is always generated at the beginning of a frame 
after an idle period. 


This differs from practice in ISO 3309, which allows 7 to 14 bit 
mark idle. 


5.5. Transmission Considerations 
All octets are transmitted least significant bit first. 


The definition of various encodings and scrambling is the 
responsibility of the DTE/DCE equipment in use, and is outside the 
scope of this specification. 


While PPP will operate without regard to the underlying 
representation of the bit stream, lack of standards for transmission 
will hinder interoperability as surely as lack of data link 
standards. At speeds of 56 Kbps through 2.0 Mbps, NRZ is currently 
most widely available, and on that basis is recommended as a default. 


When configuration of the encoding is allowed, NRZI is recommended as 
an alternative, because of its relative immunity to signal inversion 
configuration errors, and instances when it MAY allow connection 
without an expensive DSU/CSU. Unfortunately, NRZI encoding 
exacerbates the missing x1 factor of the 16-bit FCS, so that one 
error in 2**15 goes undetected (instead of one in 2**16), and triple 
errors are not detected. Therefore, when NRZI is in use, it is 
recommended that the 32-bit FCS be negotiated, which includes the xl 
factor. 


At higher speeds of up to 45 Mbps, some implementors have chosen the 
ANSI High Speed Synchronous Interface [HSSI]. While this experience 
is currently limited, implementors are encouraged to cooperate in 
choosing transmission encoding. 
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6. 


Asynchronous to Synchronous Conversion 


There may be some use of asynchronous-to-synchronous converters (some 
built into modems and cellular interfaces), resulting in an 
asynchronous PPP implementation on one end of a link and a 
synchronous implementation on the other. It is the responsibility of 
the converter to do all stuffing conversions during operation. 


To enable this functionality, synchronous PPP implementations MUST 
always respond to the Async-Control-Character-Map Configuration 
Option with the LCP Configure-Ack. However, acceptance of the 
Configuration Option does not imply that the synchronous 
implementation will do any ACCM mapping. Instead, all such octet 
mapping will be performed by the asynchronous-to-synchronous 
converter. 
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7. Additional LCP Configuration Options 


The Configuration Option format and basic options are already defined 
for LCP [1]. 


Up-to-date values of the LCP Option Type field are specified in the 
most recent "Assigned Numbers" RFC [10]. This document concerns the 
following values: 


2 Async-Control-Character-Map 


7.1. Async-Control-Character-Map (ACCM) 
Description 


This Configuration Option provides a method to negotiate the use 
of control character transparency on asynchronous links. 


Each end of the asynchronous link maintains two Async-Control- 
Character-Maps. The receiving ACCM is 32 bits, but the sending 
ACCM may be up to 256 bits. This results in four distinct ACCMs, 
two in each direction of the link. 


For asynchronous links, the default receiving ACCM is Oxffffffff. 
The default sending ACCM is Oxffffffff, plus the Control Escape 
and Flag Sequence characters themselves, plus whatever other 
outgoing characters are flagged (by prior configuration) as likely 
to be intercepted. 


For other types of links, the default value is 0, since there is 
no need for mapping. 


The default inclusion of all octets less than hexadecimal 0x20 
allows all ASCII control characters [6] excluding DEL (Delete) 
to be transparently communicated through all known data 
communications equipment. 


The transmitter MAY also send octets with values in the range 0x40 
through Oxff (except 0x5e) in Control Escape format. Since these 
octet values are not negotiable, this does not solve the problem 
of receivers which cannot handle all non-control characters. 

Also, since the technique does not affect the 8th bit, this does 
not solve problems for communications links that can send only 7- 
bit characters. 
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Note that this specification differs in detail from later 
amendments, such as 3309:1991/Amendment 2 [3]. However, such 
"extended transparency" is applied only by "prior agreement". 
Use of the transparency methods in this specification 
constitute a prior agreement with respect to PPP. 


For compatibility with 3309:1991/Amendment 2, the transmitter 
MAY escape DEL and ACCM equivalents with the 8th (most 
Significant) bit set. No change is required in the receiving 
algorithm. 


Following ACCM negotiation, the transmitter SHOULD cease 
escaping DEL. 


However, it is rarely necessary to map all control characters, and 
often it is unnecessary to map any control characters. The 
Configuration Option is used to inform the peer which control 
characters MUST remain mapped when the peer sends them. 


The peer MAY still send any other octets in mapped format, if it 
is necessary because of constraints known to the peer. The peer 
SHOULD Configure-Nak with the logical union of the sets of mapped 
octets, so that when such octets are spuriously introduced they 
can be ignored on receipt. 


A summary of the Async-Control-Character-Map Configuration Option 
format is shown below. The fields are transmitted from left to 
right. 


0 1 2 3 
01234567829 0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | ACCM 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
ACCM (cont) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


Length 
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ACCM 


The ACCM field is four octets, and indicates the set of control 
characters to be mapped. The map is sent most significant octet 
first. 


Each numbered bit corresponds to the octet of the same value. If 
the bit is cleared to zero, then that octet need not be mapped. 

If the bit is set to one, then that octet MUST remain mapped. For 
example, if bit 19 is set to zero, then the ASCII control 
character 19 (DC3, Control-S) MAY be sent in the clear. 


Note: The least significant bit of the least significant octet 


(the final octet transmitted) is numbered bit 0, and would map 
to the ASCII control character NUL. 
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A. 


B. 


Recommended LCP Options 
The following Configurations Options are recommended: 
High Speed links 


Magic Number 

Link Quality Monitoring 

No Address and Control Field Compression 
No Protocol Field Compression 


Low Speed or Asynchronous links 


Async Control Character Map 

Magic Number 

Address and Control Field Compression 
Protocol Field Compression 


Automatic Recognition of PPP Frames 


It is sometimes desirable to detect PPP frames, for example during a 
login sequence. The following octet sequences all begin valid PPP 
LCP frames: 


7e ff 03 cO 21 
7e ff "d 23 cO 21 
7e 7d df 7d 23 c0 21 


Note that the first two forms are not a valid username for Unix. 
However, only the third form generates a correctly checksummed PPP 
frame, whenever 03 and ff are taken as the control characters ETX and 
DEL without regard to parity (they are correct for an even parity 
link) and discarded. 


Many implementations deal with this by putting the interface into 
packet mode when one of the above username patterns are detected 
during login, without examining the initial PPP checksum. The 
initial incoming PPP frame is discarded, but a Configure-Request is 
sent immediately. 
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C. 


C 


Fast Frame Check Sequence (FCS) Implementation 


The FCS was originally designed with hardware implementations in 
mind. A serial bit stream is transmitted on the wire, the FCS is 
calculated over the serial data as it goes out, and the complement of 
the resulting FCS is appended to the serial stream, followed by the 
Flag Sequence. 


The receiver has no way of determining that it has finished 
calculating the received FCS until it detects the Flag Sequence. 
Therefore, the FCS was designed so that a particular pattern results 
when the FCS operation passes over the complemented FCS. A good 
frame is indicated by this "good FCS" value. 


1. FCS table generator 


The following code creates the lookup table used to calculate the 
FCS-16. 


* 
P Generate a FCS-16 table. 

* 

* Drew D. Perkins at Carnegie Mellon University. 

* 

* Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. 
*/ 

/* 


* The FCS-16 generator polynomial: x**0 + x**5 + x**12 + x**16. 
*4 
#define P 0x8408 


main() 


( 
register unsigned int b, v; 
register int i; 


printf("typedef unsigned short ul16;\n"); 


printf("static ul6 fcstab[256] = {"); 
for (b = 0; ; ) { 
if (b % 8 == 0) 
printf ("Nn"); 
v=b; 
for (i = BE ea ) 
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v=v& 1? 
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printf ("\t0x%04x", 
(++b == 256) 


at 


break; 


printf(","); 


} 


printf ("\n};\n"); 


(v >> 1) ^ 


P:3:v>> 1; 


v & OXFFFF); 


C.2. 16-bit FCS Computation Method 


The following code provides a table lookup computation for 
calculating the Frame Check Sequence as data arrives at the 
This implementation is based on [7], 


interface. 


/* 


* ul6 represents an unsigned 16-bit number. 


* your hardware. 


ey, 


typedef unsigned short ul; 


/* 


[8], 


* FCS lookup table as calculated by the table generator. 


wf 
static ul6 
0x0000, 
0x8c48, 
0x1081, 
0x9cc9, 
0x2102, 
Oxad4a, 
0x3183, 
Oxbdcb, 
0x4204, 
Oxce4c, 
0x5285, 
Oxdecd, 
0x6306, 
Oxef4e, 
0x7387, 
Oxffcf, 
0x8408, 
0x0840, 
0x9489, 
0x18c1, 
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fcstab[256] = { 


0x1189, 
Ox9dcl, 
0x0108, 
0x8d40, 
0x308b, 
Oxbcc3, 
0x200a, 
Oxac42, 
0x538d, 
Oxdfc5, 
0x430c, 
Oxcf44, 
0x728f, 
Oxfec7, 
0x620e, 
Oxee46, 
0x9581, 
0x19c9, 
0x8500, 
0x0948, 


0x2312, 
Oxaf5a, 
0x3393, 
Oxbfdb, 
0x0210, 
0x8e58, 
0x1291, 
Ox9ed9, 
0x6116, 
Oxed5e, 
0x7197, 
Oxfddf, 
0x4014, 
Oxcc5c, 
0x5095, 
Oxdcdd, 
0xa71a, 
Ox2b52, 
Oxb79b, 
0x3bd3, 


0x329b, 
Oxbed3, 
0x221a, 
0xae52, 
0x1399, 
Ox9fdl, 
0x0318, 
Ox8f50, 
0x709f, 
Oxfcd7, 
0x601e, 
Oxec56, 
0x519d, 
Oxddd5, 
Ox411c, 
Oxcd54, 
0xb693, 
Ox3adb, 
0xa612, 
Ox2a5a, 


0x4624, 
Oxca6c, 
0x56a5, 
Oxdaed, 
0x6726, 
Oxeb6e, 
Ox77a7, 
Oxfbef, 
0x0420, 
0x8868, 
Oxl4al, 
0x98e9, 
0x2522, 
0xa96a, 
0x35a3, 
Oxb9eb, 
Oxc22c, 
0x4e64, 
Oxd2ad, 
0x5ee5, 


Ox57ad, 
Oxdbe5, 
0x472c, 
Oxcb64, 
Ox76af, 
Oxfae7, 
0x662e, 
Oxea66, 
0x15a9, 
0x99e1, 
0x0528, 
0x8960, 
0x34ab, 
0xb8e3, 
0x242a, 
0xa862, 
Oxd3a5, 
Ox5fed, 
0xc324, 
Ox4f6c, 


0x6536, 
0xe97e, 
0x75b7, 
Oxf9ff, 
0x4434, 
Oxc87c, 
0x54b5, 
Oxd8fd, 
0x2732, 
Oxab7a, 
0x37b3, 
Oxbbfb, 
0x0630, 
0x8a78, 
Ox16Db1, 
Ox9af9, 
Oxel3e, 
0x6d76, 
Oxflbf, 
Ox7df7, 
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and [9]. 


Adjust the typedef for 


Ox74bf, 
Oxf8f7, 
0x643e, 
0xe876, 
0x55bd, 
Oxd9f5, 
0x453c, 
0xc974, 
0x36bb, 
Oxbaf3, 
0x263a, 
0xaa72, 
0x17b9, 
Ox9bf1, 
0x0738, 
Ox8b70, 
OxfOb7, 
Ox7cff, 
0xe036, 
Ox6c7e, 
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Oxa50a, 
0x2942, 
0xb58b, 
0x39c3, 
Oxc60c, 
0x4a44, 
0xd68d, 
Ox5ac5, 
Oxe70e, 
0x6b46, 
Oxf78f, 
Ox7bcT, 


0xb483, 
0x38cb, 
0xa402, 
0x284a, 
0xd785, 
Ox5bcd, 
0xc704, 
Ox4b4c, 
Oxf687, 
Ox7acf, 
0xe606, 
0x6a4e, 
E 


#define PPPINITFCS16 
#define PPPGOODFCS16 


/* 


0x8618, 
0x0a50, 
0x9699, 
Oxladl, 
Oxe5le, 
0x6956, 
Oxf59f, 
Ox79d7, 
Oxc41c, 
0x4854, 
0xd49d, 
0x58d5, 
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0x9791, 
Oxlbd9, 
0x8710, 
0x0b58, 
Ox£497, 
Ox78df, 
0xe416, 
0x685e, 
0xd595, 
0x59dd, 
0xc514, 
0x495c, 


0xe32e, 
Ox6f66, 
Oxf3af, 
Ox7fe7, 
0x8028, 
0x0c60, 
0x90a9, 
Oxlcel, 
Oxal2a, 
0x2d62, 
Oxblab, 
0x3de3, 


Oxffff /* 
Oxf0b8 /* 


Oxf2a7, 
Ox7eef, 
0xe226, 
0x6e6e, 
Ox91al, 
Oxlde9, 
0x8120, 
0x0d68, 
Oxb0a3, 
Ox3ceb, 
0xa022, 
Ox2c6a, 


0xc03c, 
0x4c74, 
OxdObd, 
Ox5cf5, 
0xa33a, 
0x2f72, 
Oxb3bb, 
OxStts,; 
0x8238, 
0x0e70, 
0x92b9, 
Oxlefl, 


Initial FCS value */ 
Good final FCS value */ 
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Oxd1b5, 
Ox5dfd, 
0xc134, 
Ox4d7c, 
0xb2b3, 
Ox3efb, 
0xa232, 
0x2e7a, 
0x93b1, 
Oxlff9, 
0x8330, 
0x0f78 


* Calculate a new fcs given the current fcs and the new data. 


XE 
ul6 pppfcsl6(fcs, cp, 
register ul6 fcs; 
register unsigned 
register int len; 


ASSERT (sizeof 
ASSERT ( ( (u16) 
while (len--) 

fcs = (fcs >> 


-1) 


return (fcs); 


} 
/* 


* How to use the fcs 
y 
tryfcs16 (cp, len) 
register unsigned 
register int len; 


ul6 trialfcs; 


(u16 


len) 


char *cp; 


) == 2); 
> 0); 


8) ^ festab[(fcs ^ 


char *cp; 


/* add on output */ 


trialfcs = 
trialfcs 

cp[len] = 
cp[len*1] = 
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pppfcs16( PPPINITFCS16, 
“= Oxffff; 

(trialfcs K Ox00ff); 
((trialfcs >> 8) 


Cp; 


*cp-tt) 


len 


K Oxff]l; 


); 


/* complement */ 
/* least significant byte first 
K OxOOff); 
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C. 


3. 


The following code provides a table lookup computation for 
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/* check on input */ 
pppfcsi16( PPPINITFCS16, 


trialfcs = 
LE X 


trialfcs -- 


PPPGOODFCS16 ) 


printf("Good FCS\n"); 


32-bit FCS Computation Method 


cp, len * 2 


); 
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calculating the 32-bit Frame Check Sequence as data arrives at the 


int 


/ * 


* The FCS-32 generator polynomial: 


* 
*/ 
/* 


* u32 represents an unsigned 32-bit number. 


erface. 


REKO PKL ARIE ERAAI qe AES 


+ x**7 + x**8 + x**10 + x**11 + x**12 + x**16 


+ X**22 + x**23 + x**26 + x**32. 


* your hardware. 


E 


typedef unsigned long u32; 


Static u32 fcstab 32[256] 


{ 

0x00000000, 
0x076dc419, 
0x0edb8832, 
0x09b64c2b, 
Ox1db71064, 
Oxladad47d, 
0x136c9856, 
0x14015c4f, 
0x3b6e20c8, 
0x3c03e4d1, 
0x35b5a8fa, 
0x32d86ce3, 
0x26d930ac, 
Ox21b4f4b5, 
Ox2802b89e, 
Ox2f6f7c87, 
0x76dc4190, 
0x71b18589, 
0x7807c9a2, 
Ox7f6a0dbb, 
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0x77073096, 
0x706af48f, 
Ox79dcb8a4, 
Ox7ebl7cbd, 
0x6ab020f2, 
Ox6ddde4eb, 
0x646ba8c0, 
0x63066cd9, 
0x4c69105e, 
0x4b04d447, 
0x42b2986c, 
0x45df5c75, 
0Ox51de003a, 
0x56b3c423, 
0x5f058808, 
0x58684c11, 
0x01db7106, 
Ox06b6b51f, 
Ox0f00f934, 
0x086d3d2d, 


Oxee0e612c, 
0xe963a535, 
Oxe0d5e91e, 
Oxe7b82d07, 
0xf3b97148, 
Oxf4d4b551, 
Oxfd62f97a, 
Oxfa0f3d63, 
0xd56041e4, 
Oxd20d85fd, 
Oxdbbbc9d6, 
Oxdcd60dcf, 
0xc8d75180, 
Oxcfba9599, 
Oxc60cd9b2, 
Oxcl611dab, 
0x98d220bc, 
Ox9fbfe4a5, 
0x9609a88e, 
0x91646c97, 


0x990951ba, 
0x9e6495a3, 
0x97d2d988, 
Ox90bf1d91, 
0x84be41de, 
0x83d385c7, 
0x8a65c9ec, 
0x8d080df5, 
0xa2677172, 
Oxa50ab56b, 
Oxacbcf940, 
Oxabd13d59, 
Oxbfd06116, 
Oxb8bda50f, 
Oxb10be924, 
0xb6662d3d, 
Oxefd5102a, 
0xe8b8d433, 
0xe10e9818, 
0xe6635c01, 


Adjust the typedef for 
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0x6b6b51f4, Oxlc6c6162, 0x856530d8, 0xf262004e, 
0Ox6c0695ed, Ox1b01a57b, 0x8208f4c1, Oxf50fc457, 
0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, Oxfcb9887c, 
Ox62ddlddf, 0x15da2d49, 0x8cd37cf3, Oxfbd44c65, 
0x4db26158, Ox3ab55lce, 0xa3bc0074, Oxd4bb30e2, 
Ox4adfa541, 0x3dd895d7, Oxa4d1c46d, Oxd3d6f4fb, 
0x4369e96a, 0x346ed9fc, 0xad678846, Oxda60b8d0, 
0x44042d73, 0x33031de5, 0xaa0a4c5f, O0Oxdd0d7cc9, 
0x5005713c, 0x270241aa, Oxbe0b1010, 0xc90c2086, 
0x5768b525, 0x206f85b3, 0xb966d409, O0xce61e49f, 
Ox5edef90e, 0x29d9c998, 0xb0d09822, Oxc7d7a8b4, 
0x59b33d17, Ox2eb40d81, Oxb7bd5c3b, OxcOba6cad, 
Oxedb88320, Ox9abfb3b6, 0x03b6e20c, 0x74b1d29a, 
0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, 
0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6ab5aa8, 
Oxe40ecfO0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 
Oxf00f9344, 0x8708a3d2, O0Ox1e01f268, 0x6906c2fe, 
Oxf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7, 
Oxfed41b76, 0x89d32be0, 0x10da7a5a, O0x67dd4acc, 
Oxf9b9df6f, Ox8ebeeff9, 0Ox17b7be43, 0x60Db08ed5, 
Oxd6d6a3e8, O0xald1937e, 0x38d8c2c4, Ox4fdff252, 
Oxdlbb67f1, Oxa6bc5767, Ox3fb506dd, 0x48b2364b, 
Oxd80d2bda, Oxaf0alb4c, 0x36034af6, 0x41047a60, 
Oxdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79, 
Oxcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, 
Oxcc0c7795, Oxbb0b4703, 0x220216b9, 0x5505262f, 
Oxc5ba3bbe, Oxb2bd0b28, 0x2bb45a92, 0x5cb36a04, 
Oxc2d7ffa7, Oxb5d0cf31, 0x2cd99e8b, Ox5bdeaeld, 
0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 
0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713, 
0x95bf4a82, Oxe2b87al4, Ox7bbl2bae, 0x0cb61038, 
0x92d28e9b, 0xe5d5beO0d, Ox7cdcefb7, Ox0bdbdf21, 
0Ox86d3d2d4, Oxfl1d4e242, 0x68ddb3f8, Oxlfda836e, 
Ox81bel6cd, Oxf6b9265b, 0x6fb077e1, 0x18b747771, 
0x88085ae6, Oxff0f6a70, 0x66063bca, 0x11010b5c, 
Ox8f659eff, Oxf862ae69, Ox616bffd3, 0x166ccf45, 
0xa00ae278, 0Oxd70dd2ee, 0x4e048354, 0x3903b3c2, 
0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 
Oxaedl6a4a, Oxd9d65adc, O0x40df0b66, 0x37d83bf0, 
Oxa9bcae53, Oxdebb9ec5, 0x47b2cf7f, 0x30b5ffe9, 
Oxbdbdf21c, Oxcabac28a, 0x53b39330, 0x24b4a3a6, 
Oxbad03605, Oxcdd70693, 0x54de5729, 0x23d967bf, 
0xb3667a2e, 0xc4614ab8, 0x5d681b02, Ox2a6f2b94, 
Oxb40bbe37, Oxc30c8eal, Ox5a05dflb, 0x2d02ef8d 
E 


#define PPPINITFCS32  Oxffffffff /* Initial FCS value */ 
#define PPPGOODFCS32 Oxdebb20e3 /* Good final FCS value */ 
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/* 
* Calculate a new FCS given the current FCS and the new data. 
* 

u32 pppfcs32(fcs, cp, len) 

register u32 fcs; 
register unsigned char *cp; 
register int len; 


{ 


ASSERT (sizeof (u32) == 4); 
ASSERT ( ( (u32) -1) > 0); 
while (len--) 
fcs = (((fcs) >> 8) ^ fcstab.32[((fes) ^ (*cp++)) & Oxff]); 


return (fcs); 


} 
/* 


* How to use the fcs 
*/ 
tryfcs32(cp, len) 
register unsigned char *cp; 
register int len; 


u32 trialfcs; 


/* add on output */ 
trialfcs = pppfcs32( PPPINITFCS32, cp, len ); 


trialfcs ^= Oxffffffff; /* complement */ 

cp[len] = (trialfcs K Ox00ff); /* least significant byte first */ 
cp[len*1] = ((trialfcs >>= 8) & 0Ox00ff); 

cp[len+2] = ((trialfcs >>= 8) K 0Ox00ff); 

cp[lent+3] = ((trialfcs >> 8) & 0Ox00ff); 


/* check on input */ 
trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 ); 
if ( trialfcs == PPPGOODFCS32 ) 

printf("Good FCS\n"); 
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Security Considerations 


As noted in the Physical Layer Requirements section, the link layer 
might not be informed when the connected state of the physical layer 
has changed. This results in possible security lapses due to over- 
reliance on the integrity and security of switching systems and 
administrations. An insertion attack might be undetected. An 
attacker which is able to spoof the same calling identity might be 
able to avoid link authentication. 


References 


[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 
STD 50, RFC 1661, Daydreamer, July 1994. 


[2] ISO/IEC 3309:1991(E), "Information Technology - 
Telecommunications and information exchange between systems - 
High-level data link control (HDLC) procedures - Frame 


structure", International Organization For Standardization, 
Fourth edition 1991-06-01. 


[3] ISO/IEC 3309:1991/Amd.2:1992(E), "Information Technology - 
Telecommunications and information exchange between systems - 
High-level data link control (HDLC) procedures - Frame 
structure - Amendment 2: Extended transparency options for 
start/stop transmission", International Organization For 
Standardization, 1992-01-15. 


[4] ISO/IEC 4335:1991(E), "Information Technology - 
Telecommunications and information exchange between systems - 
High-level data link control (HDLC) procedures - Elements of 
procedures", International Organization For Standardization, 
Fourth edition 1991-09-15. 


[5] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, 
Daydreamer, January 1994. 


[6] ANSI X3.4-1977, "American National Standard Code for 
Information Interchange", American National Standards 
Institute, 1977. 

[7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June 1983. 


[8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte, 
September 1986. 


Simpson [Page 24] 


RFC 1662 HDLC-like Framing July 1994 


[9] LeVan, J., "A Fast CRC", Byte, November 1987. 


[10] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 
1340, USC/Information Sciences Institute, July 1992. 


Acknowledgements 


This document is the product of the Point-to-Point Protocol Working 
Group of the Internet Engineering Task Force (IETF). Comments should 
be submitted to the ietf-ppp@merit.edu mailing list. 


This specification is based on previous RFCs, where many 
contributions have been acknowleged. 


The 32-bit FCS example code was provided by Karl Fox (Morning Star 
Technologies). 


Special thanks to Morning Star Technologies for providing computing 
resources and network access support for writing this specification. 


Chair’s Address 
The working group can be contacted via the current chair: 
Fred Baker 
Advanced Computer Communications 
315 Bollay Drive 


Santa Barbara, California 93117 


flhaker@acc.com 


Editor’s Address 
Questions about this memo can also be directed to: 


William Allen Simpson 

Daydreamer 

Computer Systems Consulting Services 
1384 Fontaine 

Madison Heights, Michigan 48071 


Bill.Simpson@um.cc.umich.edu 
bsimpson@MorningStar.com 


Simpson [Page 25] 


